During a transaction between two parties, each party typically wants assurances as to the authenticity of the identity, permissions and/or the data relating to the other party so as to avoid a variety of problems, including fraud and transaction repudiation. Such transactions can be either payment or non-payment in nature. In non-payment transactions, for example, one party may want to confirm the identity of the other party before disclosing certain information (e.g., in the exchange of non-payment data such as health care information, personal information, confidential information, or similar information). On the other hand, during a payment transaction using a payment instrument (e.g., a credit, debit, or stored value card), it is important to verify a user's ownership of an account to avoid unauthorized use of the payment instrument. Also, during payment transactions, it may be necessary to communicate payment information (such as an account number or the like) to be used in performing the transaction. For purposes of this application, references to “transactions” shall include both payment and non-payment transactions.
Authentication procedures during transactions when two parties are interacting in each other's physical presence (referred to as “in-person” transactions) can involve verifying that the signature of a user matches the signature on a piece of identification or a payment instrument, such as a credit card. Another authentication procedure involves verifying that a photograph contained in a form of identification, such as a driver's license, matches the physical appearance of the user.
However, transactions initiated and accomplished over a public network, such as the Internet, are riskier because the “in-person” authentication procedures cannot be performed. Such transactions can be initiated from devices such as but not limited to mobile phones, “smartphones,” Internet-connected computers or terminals, or Personal Digital Assistants (PDAs). Techniques known in the art, such as the use of user-name/password pairs, have disadvantages. First, parties wishing to authenticate themselves or their profiles must remember multiple such user-names and passwords, as different relying parties require different sets of authentication information. Second, user-names and passwords are not inherently capable of conveying an arbitrary set of authentication claims. A user-name and password serve only to assure the relying party that the authenticating party is who he claims, but cannot serve to assure the relying party of any assurances made about the authenticating party's identity by third parties (“issuers”). Given the continuing increase in the number of transactions that take place over public networks, it is important to provide methods to authenticate the identity and profile data of individuals. Authentication techniques during such transactions will reduce the levels of fraud and disputes, which in turn will reduce the costs associated with each of these events.
Another technique for authentication is the use of identity metasystems, such as Microsoft's CardSpace. CardSpace can provide methods and systems for authenticating the identity and permissions and validating the profile data of an individual (“a presenter”) who presents him or herself to another party (“a relying party”) as having a certain identity and permissions and having certain corresponding profile data, and relying on that authentication so as to allow a transaction, such as a payment, to proceed. An “identity” is a set of one or more claims relating to the presenter. A “claim” represents a fact about the presenter. Claims can include assertions that the presenter is a specific person, that the presenter is a certain age, the presenter is licensed to drive, etc. The presenter may be asserting a self-issued identity or an identity issued by a third-party (“the issuer”). For example, a driver's license corresponds to a particular identity and is issued by the government, while an organization membership card (such as a car club or gym membership) corresponds to another identity and is issued by the organization.
CardSpace provides a method for providing assurance of a presenter's identity to a relying party, such as a merchant, over a public network. The relying party sends a “policy” to the presenter. The policy is a set of requirements that can be used to determine which of possibly multiple presenter identities should be used in the transaction. For example, the policy could indicate that the relying party requires a government issued identity. The presenter may then select from among a set of qualifying identities. A request is then made to the issuer corresponding to the appropriate identity for electronic data corresponding to the specific identity. The electronic data is sent by the issuer through the CardSpace system, to the presenter. The presenter reviews the data and decides whether to send it to the relying party. The relying party can receive the data, through which the identity of the presenter can be authenticated. If the policy permits a self-issued card to be used, then the process is the same, except that there is no need to interact with a third-party issuer.
A system for authenticating the identity and profile data of an individual during a transaction, such as a payment transaction, over a public network would be desirable. Such an authenticating system should be relatively easy to implement and use, require a minimal investment of resources, and provide a high level of interoperability between the system's participants.